1). Field of the Invention
This invention relates to a graphical user interface, in particular, to a graphical user interface and background methodology for creating references between software components.
2). Discussion of Related Art
In a rudimentary form, many software applications developed in component based environments consist of a number of granules of software, known as “components” or “component instances,” (e.g., session beans, entity beans, etc.) and other items such as web pages and servlets. Each component is a small building block of the larger software application. When enough of the components are combined, the software acquires a particular method or functionality. Some examples of component based architectures include Java Beans (JB), Enterprise Java Beans (EJB), Common Object Request Broker Architecture (CORBA), Component Object Model (COM), Distributed Component Object Model (DCOM) and derivatives there from.
The functional granularity offered by a plurality of different components provides a platform for developing a multitude of more comprehensive tasks. For example, a business application that graphically presents the results of calculations made to an individual's financial records (e.g., amortization of interest payments, growth in income, etc.) may be created by logically stringing together: 1) an instance of a first component that retrieves an individual's financial records from a database; 2) an instance of a second component that performs calculations upon financial records; and, 3) an instance of a third component that graphically presents financial information.
Moreover, within the same environment, another business application that only graphically presents an individual's existing financial records may be created by logically stringing together: 1) another instance of the first component mentioned just above; and, 2) another instance of the third component mentioned above. That is, different instances of the same component may be used to construct different applications. The number of components within a particular environment and the specific function(s) of each of the components within the environment are determined by the developers of the environment.
Components may also be created to represent separate instances of persistent data (e.g., a first component that represents a first row of database information, a second component that represents a second row of database information, etc.) or to build textual pages (e.g., web pages) from which the execution of more complex background methods are triggered. A servlet is one type of component used to build a textual page.
FIG. 1A illustrates a computing system network 10 including a client 12, a network 14, and a server 16. The server 16 contains a web component container 18 and a business logic component container 20 that includes components used to implement complex business logic methods. The business logic component container 20 includes multiple business logic components 22 and 24 (e.g. entity and session “beans” in the case of a Java environment), and although not illustrated it should be understood that the web component container 18 includes source files for other items, such as web pages and servlets.
The web component container 18 may contain components from which web pages or other textual files (e.g., servlets) used for invoking an application's business logic method components are constructed. As illustrated, the user has accessed the web component container 18 within the server 16 and depending on the particular software application being used, the user may need to access one or more of the business logic components 22 and 24 within the business logic component container 20, as often the source files within a business application call upon or use other source files.
At least in a Java environment, “deployment descriptors” are used, among other things, to describe relationships between separate items of software. For example, a deployment descriptor can be used to facilitate the interaction between different components so that the components themselves need not be changed to call upon or use other components. These deployment descriptors would include what are known as “references.” The references can indicate, for example, how one component will interact with another component using one or more interfaces of the other component.
According to various component based architectures, components have interfaces to which the references are made. For example, in an Enterprise Java Bean (EJB) environment, there are four interfaces that a reference can identify to access a bean: a remote interface 26, a remote home (or home) interface 28, a local interface 30, and a local home interface 32 as illustrated in FIG. 1A. When two components (which in the case of EJB are two “beans”) from different containers are “connected” by a reference, the remote and remote home interfaces are used. However, when two components from the same container are referenced, the local and local home interfaces are used.
The remote home and local home interfaces are used for simple functions such as finding and deleting its constituent component. The remote and local interfaces are used to invoke the substantive methods of its particular component. In an EJB environment, the client 12 is not able to communicate with the bean instance 22 and 24 directly (i.e., is only able to use the bean instance 22 and 24 through interfaces 26, 28, 30, and 32); and, each bean instance 22 and 24 has only one home interface but is capable of having multiple remote interfaces (e.g., one remote interface for each separate client that is engaged in a communication session with).
As illustrated in FIG. 1A, component 22 is being accessed by an item from within the web container 18, therefore, the remote home 28 and remote 26 interfaces of component 22 are being used by references 341 and 342 to access component 22. On the other hand, component 24 is being accessed by component 22, which is also in the business logic component container 20, therefore, the local home 32 and local 30 interfaces are being used by reference 351 and 352 to access component 24.
Organizations that create business applications use programs that are known as “deployment” or “deploy” tools to deploy the business applications from the component source files to the particular server that is going to utilize the applications.
The desired component source files are first tagged as the sources that are to be combined into the final business application. FIG. 1B illustrates a deployment environment 36 including a storage facility 38 of a computing system (e.g., a hard drive), a deployment tool 40, and a server 42 to receive deployed files. The computing system storage 38, which may actually comprise multiple computing subsystems, has multiple source files 44. In a Java environment, a portion of the deployment tool known as an “archive builder” 46 copies the source files 44 from the computer system storage 38 and compresses them into archive files 48 (e.g., a “.jar” file for Java beans, a “.war” file for Java web components, etc.). Another portion of the deployment tool 40, the “assembler,” 50 may then combine different archive files 48 into an enterprise archive file 52 (e.g., an “.ear” file). Finally, the “deployer,” 54 another portion of the deployment tool 40, sends the enterprise archive file 52 to the server 42 onto which the business application will be loaded. The server 42 “unpacks” the enterprise archive file 52 and loads the components 44.
Additionally, before the business application can be deployed to the destination server 42, the proper references between software components must be established. According to prior art approaches, in order for the archive builder 46 to create appropriate references between source files, a software engineer had to manual type the name or address of each interface into the deployment tool, which recently have begun to utilize GUIs (Graphical User Interfaces) to facilitate the process of deploying business applications.
FIG. 2 illustrates a prior art GUI 56 for creating references between component source files. The GUI 56 includes utility pull down menus 58, utility buttons 60, and first level tabs 62.
Within the displayed first level tab 62 is a component window 64 and two second level tabs 66, the first of which is displayed and includes a reference window 68 and a reference information window 70. The reference information window 70 includes multiple fields: a reference name field 72, a home interface field 74, a remote interface field 76, and a reference link field 78. The reference information window 70 also includes a component type indicator 80, an add button 82, a remove button 84, and a clear button 86.
In use, from the component source files, the components of a project are listed within the component window 64. The user selects the component from which the reference will be made (i.e., the source component) from the component window 64. In order to create a proper reference, the user must then manually type the name of the component to which the reference will be made (i.e., the target component) into the reference link field 78. The user must also manually type the type of interfaces being referred to into either the home 74 and remote 76 interface fields and type the name of the reference into the reference name field 72 before clicking the add button 82 to finish the reference, which is then displayed in the reference window 68. The reference is then instantiated into a deployment descriptor.
The names, or addresses, of the interfaces and the components themselves can be very long and confusing. Properly typing the required information into the appropriate field is very time consuming and arduous, even for an experienced user. Mistakes are often made in this process, which results in the business application not working properly.
It is important to emphasize that although alternative component designs may exist that depart from existing EJB specifications in various respects, it is possible that environments that use such alternative component designs can take advantage of the teachings being described herein.